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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document establishes the minimum performance requirements for A-GNSS (including A-GPS) for FDD or 
TDD mode of E-UTRA for the User Equipment (UE). 
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The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 36.101: "Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) 
radio transmission and reception". 

[2] 3GPP TS 36. 104: "Evolved Universal Terrestrial Radio Access (E-UTRA); Base Station (BS) 

radio transmission and reception". 

[3] 3GPP TS 36.yyy: "Evolved Universal Terrestrial Radio Access (E-UTRA); Terminal 

Conformance Specification, Assisted Global Navigation Satellite System (A-GNSS)". 

[4] 3GPP TS 36.355: "Evolved Universal Terrestrial Radio Access (E-UTRA); LTE Positioning 

Protocol (LPP)". 

[5] 3GPP TS 36.302: "Evolved Universal Terrestrial Radio Access (E-UTRA); Services provided by 

the physical layer" . 

[6] 3GPP TS 36.214: "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer; 

Measurements". 

[7] ETSI TR 102 273-1-2: "Electromagnetic compatibility and Radio spectrum Matters (ERM); 

Improvement on Radiated Methods of Measurement (using test site) and evaluation of the 
corresponding measurement uncertainties; Part 1: Uncertainties in the measurement of mobile 
radio equipment characteristics; Sub-part 2: Examples and annexes". 

[8] IS-GPS-200, Revision D, Navstar GPS Space Segment/Navigation User Interfaces, March 7*, 

2006. 

[9] P. Axelrad, R.G. Brown, "GPS Navigation Algorithms", in Chapter 9 of "Global Positioning 

System: Theory and Applications", Volume 1, B.W. Parkinson, J.J. Spilker (Ed.), Am. Inst, of 
Aeronautics and Astronautics Inc., 1996. 

[10] S.K. Gupta, "Test and Evaluation Procedures for the GPS User Equipment", lON-GPS Red Book, 

Volume l,p. 119. 

[II] 3GPP TS 36.509: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Packet 
Core (EPC); Special conformance testing functions for User Equipment (UE)". 

[12] IS-GPS-705, Navstar GPS Space Segment/User Segment L5 Interfaces, September 22, 2005. 

[13] IS-GPS-800, Navstar GPS Space Segment/User Segment LlC Interfaces, September 4, 2008. 

[14] IS-QZSS, Quasi Zenith Satellite System Navigation Service Interface Specifications for QZSS, 

Ver.1.1, July 31, 2009. 



£75/ 



3GPP TS 36.171 version 9.0.0 Release 9 



ETSI TS 136 171 V9.0.0 (2010-04) 



[15] 

[16] 
[17] 



Galileo OS Signal in Space ICD (OS SIS ICD), Draft 0, Galileo Joint Undertaking, May 23"*, 
2006. 

Global Navigation Satellite System GLONASS Interface Control Document, Version 5.1, 2008. 

Specification for the Wide Area Augmentation System (WAAS), US Department of 
Transportation, Federal Aviation Administration, DTFA01-96-C-00025, 2001. 



Definitions, symbols and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions given in 3GPP TS 36.101 [1], 3GPP TS 36.104 [2] 
and the following apply: 

Horizontal Dilution Of Precision (HDOP): measure of position determination accuracy that is a function of the 
geometrical layout of the satellites used for the fix, relative to the receiver antenna 



3.2 Symbols 



For the purposes of the present document, the following symbols apply: 



El 
E5 
E6 
Gl 

G2 

k 

LI C/A 

Lie 
L2C 
L5 
G 

PcNSS„ ,i 

W 



Galileo El navigation signal with carrier frequency of 1575.420 MHz. 

Galileo E5 navigation signal with carrier frequency of 1 191.795 MHz. 

Galileo E6 navigation signal with carrier frequency of 1278.750 MHz. 

GLONASS navigation signal in the LI sub-bands with carrier frequencies 1602 MHz + k x 562.5 

kHz. 

GLONASS navigation signal in the L2 sub-bands with carrier frequencies 1246 MHz + k x 437.5 

kHz. 

GLONASS channel number, k = -7. . . 13. 

GPS or QZSS LI navigation signal carrying the Coarse/ Acquisition code with carrier frequency of 

1575.420 MHz. 

GPS or QZSS LI Civil navigation signal with carrier frequency of 1575.420 MHz. 

GPS or QZSS L2 Civil navigation signal with carrier frequency of 1227.600 MHz. 

GPS or QZSS L5 navigation signal with carrier frequency of 1 176.450 MHz. 

Geometry Matrix. 

Measured pseudo-range of satellite i of GNSSm- 
Weighting Matrix. 

Line of sight unit vector from the user to the satellite / of GNSSm. 
State vector of user position and clock bias. 



3.3 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

A-GNSS Assisted Global Navigation Satelhte System 

A-GPS Assisted - Global Positioning System 

AWGN Additive White Gaussian Noise 

C/A Coarse/Acquisition 

DUT Device Under Test 

ECEF Earth Centred, Earth Fixed 

ECI Earth-Centered-Inertial 

E-SMLC Enhanced Serving Mobile Location Centre 

E-UTRA Evolved UMTS Terrestrial Radio Access 

E-UTRAN Evolved UMTS Terrestrial Radio Access Network 

eNB E-UTRAN Node B 
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FDD Frequency Division Duplex 

GLONASS GLObal'naya NAvigatsionnaya Sputnikovaya Sistema (Engl.: Global Navigation Satellite System) 

GNSS Global Navigation Satellite System 

GPS Global Positioning System 

GSS GPS System Simulator 

HDOP Horizontal Dilution Of Precision 

ICD Interface Control Document 

IS Interface Specification 

LOS Line Of Sight 

LPP LTE Positioning Protocol 

QZSS Quasi-Zenith Satellite System 

RRC Radio Resource Control 

SBAS Space Based Augmentation System 

SFN System Frame Number 

SS FDD System simulator 

SV Space Vehicle 

TDD Time Division Duplex 

TLM TeLeMetry word. It contains an 8-bits preamble (1000101 1) 

TOW Time Of Week 

TTFF Time To First Fix 

UE User Equipment 

WLS Weighted Least Square 

WGS-84 World Geodetic System 1984 

3.4 Test tolerances 

The requirements given in the present document make no allowance for measurement uncertainty. The test specification 
3GPP TS 36.yyy [3] defines test tolerances. These test tolerances are individually calculated for each test. The test 
tolerances are then added to the limits in the present document to create test limits. The measurement results are 
compared against the test limits as defined by the shared risk principle. 

Shared Risk is defined in ETR 273-1-2 [7], subclause 6.5. 



4 General 

4.1 Introduction 

The present document defines the minimum performance requirements for both UE based and UE assisted FDD or 
TDD A-GNSS (including A-GPS) terminals. 

4.2 Measurement parameters 

4.2.1 UE based A-GNSS measurement parameters 

In case of UE-based A-GNSS, the measurement parameters are contained in the GNSS-Locationlnformation IE which is 
included in the A-GNSS-ProvideLocationlnformation IE provided in the LPP message of type PROVIDE LOCATION 
INFORMATION. The measurement parameter in case of UE-based A-GNSS is the horizontal position estimate 
reported by the UE and expressed in latitude/longitude. 

4.2.2 UE assisted A-GNSS measurement parameters 

In case of UE-assisted A-GNSS, the measurement parameters are contained in the 

GNSS-SingnalMeasurementlnformation IE which is included in the A-GNSS-ProvideLocationlnformation IE provided 
in the LPP message of type PROVIDE LOCATION INFORMATION. The measurement parameters in case of UE- 
assisted A-GNSS are the UE GNSS code phase measurements, as specified in 3GPP TS 36.302 [5] and 3GPP TS 
36.214 [6]. The UE GNSS code phase measurements are converted into a horizontal position estimate using the 
procedure detailed in Annex F. 
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4.3 Response time 



Max Response Time is defined as the time starting from the moment that the UE has received the LPP message of type 
REQUEST LOCATION INFORMATION, and ending when the UE starts sending the LPP message of type PROVIDE 
LOCATION INFORMATION on the Uu interface. The response times specified for all test cases are Time-to-First-Fix 
(TTFF) unless otherwise stated, i.e. the UE shall not re-use any information on GNSS time, location or other aiding data 
that was previously acquired or calculated and stored internally in the UE. A dedicated test message 'RESET UE 
POSITIONING STORED INFORMATION' has been defined in TS 36.509 [11] clause 6.9 for the purpose of deleting 
this information and is detailed in subclause B.1.10. 

4.4 Time assistance 

Time assistance is the provision of GNSS time to the UE from the network via LPP messages. Currently two different 
GNSS time assistance methods can be provided by the network. 

a) Coarse time assistance is always provided by the network and provides current GNSS time to the UE. The time 
provided is within ±2 seconds of GNSS system time. It is signalled to the UE by means of the gnss-DayNumber 
and gnss-TimeOfDay fields in the gnss-SysteniTime IE. 

b) Fine time assistance is optionally provided by the network and adds the provision to the UE of the relationship 
between the GNSS system time and the current E-UTRAN time. The accuracy of this relationship is ±10 jis of 
the actual relationship. This addresses the case when the network can provide an improved GNSS time accuracy. 
It is signalled to the UE by means of the gnss-SystemTime IE and the gnss-ReferenceTimeForCells IE. 

The specific GNSS system time is identified through the gnss-TimelD field of the GNSS-SystemTime IE. In case where 
several GNSSs are used in the tests, only one gnss-TimelD is used to determine the Time of Day. For all the 
constellations, the gnss-TimeModels IE shall be available at the system simulator, as specified in Annex E. 

4.4.1 Use of fine time assistance 

The use of fine time assistance to improve the GNSS performance of the UE is optional for the UE, even when fine time 
assistance is signalled by the network. Thus, there are a set minimum performance requirements defined for all UEs and 
additional minimum performance requirements that are valid for fine time assistance capable UEs only. These 
requirements are specified in subclause 5.1.2 for UEs that support A-GPS LI C/A only and in clause 6.1.2 for UEs that 
support other GNSSs. 

4.5 RRC states 

The minimum A-GNSS performance requirements are specified in clauses 5 and 6 for RRC_CONNECTED state. The 
test and verification procedures are separately defined in annex B. 

4.6 Error definitions 

The 2D position error is defined by the horizontal difference in meters between the ellipsoid point reported or calculated 
from the LPP message of type PROVIDE LOCATION INFORMATION and the actual position of the UE in the test 
case considered. 

4.7 UEs supporting multiple constellations 

Minimum performance requirements are defined for each global GNSS constellation (GPS, Galileo, Modernized GPS, 
and GLONASS). UEs supporting multiple global constellations shall meet the minimum performance requirements for 
a combined scenario where each UE supported constellation is simulated. 

NOTE: For test cases where signals from 'GPS' and 'Modernized GPS' are included, 'GPS' and 'Modernized GPS' 
are considered as a single constellation, unless otherwise specified. 
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4.8 UEs supporting multiple signals 

For UEs supporting multiple signals, different minimum performance requirements may be associated with different 
signals. The satellite simulator shall generate all signals supported by the UE. Signals not supported by the UE do not 
need to be simulated. The relative power levels of each signal type for each GNSS are defined in Table 4.1. The 
individual test scenarios in clause 6 define the reference signal power level for each satellite. The power level of each 
simulated satellite signal type shall be set to the reference signal power level defined in each test scenario in clause 6 
plus the relative power level defined in Table 4.1. 

Table 4.1 : Relative signal power levels for each signal type for each GNSS 





Galileo 


GPS/Modernized 
GPS 


GLONASS 


QZSS 


SBAS 


Signal power levels 
relative to 
reference power 
levels 


E1 


OdB 


L1 C/A 


OdB 


G1 


OdB 


LI C/A 


OdB 


LI 


OdB 


E6 


+2dB 


L1C 


+1.5 dB 


G2 


-6dB 


Lie 


+1.5dB 






E5 


+2dB 


L2C 


-1.5 dB 






L2C 


-1.5dB 










L5 


+3.6 dB 






L5 


+3.6 dB 







NOTE 1: For test cases which involve 'Modernized GPS', the satellite simulator shall also generate the GPS LI C/A 
signal if the UE supports 'GPS' in addition to 'Modernized GPS'. 

NOTE 2: The signal power levels in the Test Parameter Tables represent the total signal power of the satellite per 
channel not e.g. pilot and data channels separately. 



5 A-GNSS minimum performance requirements (UE 

supports A-GPS L1 C/A only) 

The minimum performance requirements specified in clause 5 apply for UEs that support A-GPS LI C/A only. The 
requirements for UEs that support other or additional A-GNSSs are specified in clause 6. 

The A-GNSS minimum performance requirements are defined by assuming that all relevant and valid assistance data is 
received by the UE in order to perform GPS LI C/A measurements and/or position calculation. This clause does not 
include nor consider delays occurring in the various signalling interfaces of the network. 

In the following subclauses the minimum performance requirements are based on availability of the assistance data 
information and messages defined in annexes D and E. 



5.1 Sensitivity 



A sensitivity requirement is essential for verifying the performance of A-GNSS receiver in weak satellite signal 
conditions. In order to test the most stringent signal levels for the satellites the sensitivity test case is performed in 
AWGN channel. This test case verifies the performance of the first position estimate, when the UE is provided with 
only coarse time assistance and when it is additionally supplied with fine time assistance. 

5.1.1 Coarse time assistance 

In this test case 8 satellites are generated for the terminal. AWGN channel model is used. 
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Table 5.1 : Test parameters 



Parameters 


Unit 


Value 


Number of generated satellites 


- 


8 


HDOP Range 


- 


1.1 to 1.6 


Propagation conditions 


- 


AWGN 


GNSS Coarse time assistance error 
range 


seconds 


+2 


GPS L1 G/A Signal for one satellites 


dBm 


-142 


GPS L1 C/A Signal for remaining 
satellites 


dBm 


-147 



5.1 .1 .1 Minimum Requirements (Coarse time assistance) 

The position estimates shall meet the accuracy and response time specified in Table 5.2. 

Table 5.2: Minimum requirements (coarse time assistance) 



Success rate 


2-D position error 


IVIax response time 


95% 


100 m 


20 s 



5.1 .2 Fine time assistance 

This requirement is only valid for fine time assistance capable UEs. In this requirement 8 satellites are generated for the 
terminal. AWGN channel model is used. 

Table 5.3: Test parameters for fine time assistance capable terminals 



Parameters 


Unit 


Value 


Number of generated satellites 


- 


8 


HDOP Range 


- 


1.1 to 1.6 


Propagation conditions 


- 


AWGN 


GNSS Coarse time assistance error range 


seconds 


+2 


GPS LI C/A Fine time assistance error 
range 


lis 


+10 


GPS LI C/A Signal for all satellites 


dBm 


-147 



5.1 .2.1 Minimum Requirements (Fine time assistance) 

The position estimates shall meet the accuracy and response time requirements in Table 5.4. 

Table 5.4: Minimum requirements for fine time assistance capable terminals 



Success rate 


2-D position error 


Max response time 


95% 


100 m 


20 s 



5.2 Nominal Accuracy 



Nominal accuracy requirement verifies the accuracy of A-GNSS position estimate in ideal conditions. The primarily 
aim of the test is to ensure good accuracy for a position estimate when satellite signal conditions allow it. This test case 
verifies the performance of the first position estimate. 

In this requirement 8 satellites are generated for the terminal. AWGN channel model is used. 
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Table 5.5: Test parameters 



Parameters 


Unit 


Value 


Number of generated satellites 


- 


8 


HDOP Range 


- 


1.1 to 1.6 


Propagation conditions 


- 


AWGN 


GNSS Coarse time assistance error 
range 


seconds 


+2 


GPS L1 C/A Signal for all satellites 


dBm 


-130 



5.2.1 Minimum requirements (nominal accuracy) 

The position estimates shall meet the accuracy and response time requirements in Table 5.6. 

Table 5.6: Minimum requirements 



Success rate 


2-D position error 


Max response time 


95% 


30 m 


20 s 



5.3 Dynamic Range 



The aim of a dynamic range requirement is to ensure that a GNSS receiver performs well when visible satellites have 
rather different signal levels. Strong satellites are likely to degrade the acquisition of weaker satellites due to their 
cross-correlation products. Hence, it is important in this test case to keep use AWGN in order to avoid loosening the 
requirements due to additional margin because of fading channels. This test case verifies the performance of the first 
position estimate. 

In this requirement 6 satellites are generated for the terminal. AWGN channel model is used. 

Table 5.7: Test parameters 



Parameters 


Unit 


Value 


Number of generated satellites 


- 


6 


HDOP Range 


- 


1.4 to 2.1 


GNSS Coarse time assistance 
error range 


seconds 


+2 


Propagation conditions 


- 


AWGN 


GPS LI C/A Signal for l^t satellite 


dBm 


-129 


GPS LI C/A Signal for 2"^ satellite 


dBm 


-135 


GPS LI C/A Signal for 3'''^ satellite 


dBm 


-141 


GPS LI C/A Signal for 4* satellite 


dBm 


-147 


GPS LI C/A Signal for 5* satellite 


dBm 


-147 


GPS LI C/A Signal for 6* satellite 


dBm 


-147 



5.3.1 Minimum requirements (dynamic range) 

The position estimates shall meet the accuracy and response time requirements in Table 5.8. 

Table 5.8: Minimum requirements 



Success rate 


2-D position error 


Max response time 


95% 


100 m 


20 s 
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5.4 



Multi-Path scenario 



The purpose of the test case is to verify the receiver's tolerance to muhipath while keeping the test setup simple. This 
test case verifies the performance of the first position estimate. 

In this requirement 5 satellites are generated for the terminal. Two of the satellites have one tap channel representing 
Line-Of-Sight (LOS) signal. The three other satellites have two-tap channel, where the first tap represents LOS signal 
and the second reflected and attenuated signal as specified in Annex C.2. 

Table 5.9: Test parameters 



Parameters 


Unit 


Value 


Number of generated satellites (Satellites 1 , 2 

unaffected by multi-path) 

(Satellites 3, 4, 5 affected by multi-path) 




5 


GNSS Coarse time assistance error range 


seconds 


+2 


HDOP Range 


- 


1.8 to 2.5 


GPS L1 C/A Signal for satellite 1 , 2 


dBm 


-130 


GPS L1 C/A Signal for satellite 3, 4, 5 


dBm 


LOS signal of -130 dBm, multi- 
path signal of -136 dBm 



5.4.1 IVIinimum Requirements (multi-path scenario) 

The position estimates shall meet the accuracy and response time requirements in Table 5.10. 

Table 5.10: Minimum requirements 



Success rate 


2-D position error 


Max response time 


95% 


100 m 


20 s 



5.5 IVIoving scenario and periodic update 

The purpose of the test case is to verify the receiver's capability to produce GNSS measurements or location fixes on a 
regular basis, and to follow when it is located in a vehicle that slows down, turns or accelerates. A good tracking 
performance is essential for a certain location services. A moving scenario with periodic update is well suited for 
verifying the tracking capabilities of an A-GNSS receiver in changing UE speed and direction. In the requirement the 
UE moves on a rectangular trajectory, which imitates urban streets. AWGN channel model is used. This test is not 
performed as a Time to First Fix (TTFF) test. 

In this requirement 5 satellites are generated for the terminal. The UE is requested to use periodical reporting with a 
reporting interval of 2 seconds. 

The UE moves on a rectangular trajectory of 940 m by 1 440 m with rounded corner defined in Figure 5.1. The initial 
reference is first defined followed by acceleration to final speed of 100 km/h in 250 m. The UE then maintains the 
speed for 400 m. This is followed by deceleration to final speed of 25 km/h in 250 m. The UE then turn 90 degrees with 
turning radius of 20 m at 25 km/h. This is followed by acceleration to final speed of 100 km/h in 250 m. The sequence 
is repeated to complete the rectangle. 

Table 5.11 : Trajectory Parameters 



Parameter 


Distance (m) 


Speed (km/h) 


'l1' 'l5' '2I' '25 


20 


25 


'l2' 'l4' '22- '24 


250 


25 to 100 and 100 to 25 


Il3 


400 


100 


'23 


900 


100 
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Figure 5.1 : Rectangular trajectory of the moving scenario and periodic update test case 

Table 5.12: Test Parameters 



Parameters 


Unit 


Value 


Number of generated satellites 


- 


5 


HDOP Range 


- 


1.8 to 2.5 


Propagation condition 


- 


AWGN 


GPS L1 C/A signal for all 
satellites 


dBm 


-130 



5.5.1 Minimum Requirements (moving scenario and periodic update) 

The position estimates shall meet the accuracy requirement of Table 5.13 with the periodical reporting interval defined 
in Table 5.13 after the first reported position estimates. 



NOTE: 



In the actual testing the UE may report error messages until it has been able to acquire GNSS measured 
results or a position estimate. The test equipment shall only consider the first measurement report 
different from an error message as the first position estimate in the requirement in Table 5.13. 

Table 5.13: Minimum requirements 



Success Rate 


2-D position error 


Periodical reporting interval 


95% 


100 m 


2s 



6 A-GNSS minimum performance requirements (UE 

supports other or additional GNSSs) 

The minimum performance requirements specified in clause 6 apply for UEs that support other A-GNSSs than GPS LI 
C/A, or multiple A-GNSSs which may or may not include GPS LI C/A. The requirements for UEs that support A-GPS 
LI C/A only are specified in clause 5. 

The A-GNSS minimum performance requirements are defined by assuming that all relevant and valid assistance data is 
received by the UE in order to perform GNSS measurements and/or position calculation. This clause does not include 
nor consider delays occurring in the various signalling interfaces of the network. 

In the following subclauses the minimum performance requirements are based on availability of the assistance data 
information and messages defined in annexes D and E. 
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6.1 Sensitivity 



A sensitivity requirement is essential for verifying the performance of A-GNSS receiver in weak satellite signal 
conditions. In order to test the most stringent signal levels for the satellites the sensitivity test case is performed in 
AWGN channel. This test case verifies the performance of the first position estimate, when the UE is provided with 
only coarse time assistance and when it is additionally supplied with fine time assistance. 

6.1.1 Coarse time assistance 

In this test case 6 satellites are generated for the terminal. AWGN channel model is used. 

Table 6.1 : Test parameters 



System 


Parameters 


Unit 


Value 




Number of generated satellites per system 


- 


See Table 6.2 


Total number of generated satellites 


- 


6 


HDOP range 




1.4 to 2.1 


Propagation conditions 


- 


AWGN 


GNSS coarse time assistance error range 


seconds 


+2 


Galileo 


Reference high signal power level 


dBm 


TBD 




Reference low signal power level 


dBm 


TBD 


GPS'" 


Reference high signal power level 


dBm 


-142 




Reference low signal power level 


dBm 


-147 


GLONASS 


Reference high signal power level 


dBm 


-142 




Reference low signal power level 


dBm 


-147 


NOTE 1 : "GPS" here means GPS L1 G/A, Modernized GPS, or both, dependent on UE 
capabilities. 



Table 6.2: Power level and satellite allocation 







Satellite allocation for each 
constellation 




GNSS-1^" 


GNSS-2 


GNSS-3 


Single constellation 


High signal level 


1 


- 


- 


Low signal level 


5 


- 


- 


Dual constellation 


High signal level 


1 


- 


- 


Low signal level 


2 


3 


- 


Triple constellation 


High signal level 


1 


- 


- 


Low signal level 


1 


2 


2 


Note 1 : For GPS capable receivers, GNSS-1 , i.e. the system having the 
satellite with high signal level, shall be GPS. 



6.1 .1 .1 Minimum Requirements (Coarse time assistance) 

The position estimates shall meet the accuracy and response time specified in Table 6.3. 

Table 6.3: Minimum requirements (coarse time assistance) 



System 


Success rate 


2-D position error 


Max response time 


All 


95% 


100 m 


20 s 



6.1 .2 Fine time assistance 

This requirement is only valid for fine time assistance capable UEs. In this requirement 6 satellites are generated for the 
terminal. AWGN channel model is used. 
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Table 6.4: Test parameters 



System 


Parameters 


Unit 


Value 




Number of generated satellites per system 


- 


See Table 6.5 


Total number of generated satellites 


- 


6 


HDOP range 




1.4 to 2.1 


Propagation conditions 


- 


AWGN 


GNSS coarse time assistance error range 


seconds 


+2 


GNSS fine time assistance error range 


us 


±10 


Galileo 


Reference signal power level 


dBm 


TBD 


GPS*" 


Reference signal power level 


dBm 


-147 


GLONASS 


Reference signal power level 


dBm 


-147 


NOTE 1 : "GPS" here means GPS L1 G/A, Modernized GPS, or both, dependent on UE 
capabilities. 



Table 6.5: Satellite allocation 





Satellite allocation for each 
constellation 


GNSS-1 


GNSS-2 


GNSS-3 


Single constellation 


6 


- 


- 


Dual constellation 


3 


3 


- 


Triple constellation 


2 


2 


2 



6.1 .2.1 Minimum Requirements (Fine time assistance) 

The position estimates shall meet the accuracy and response time requirements in Table 6.6. 

Table 6.6: Minimum requirements for fine time assistance capable terminals 



System 


Success rate 


2-D position error 


Max response time 


All 


95% 


100 m 


20 s 



6.2 Nominal Accuracy 



Nominal accuracy requirement verifies the accuracy of A-GNSS position estimate in ideal conditions. The primarily 
aim of the test is to ensure good accuracy for a position estimate when satellite signal conditions allow it. This test case 
verifies the performance of the first position estimate. 

In this requirement 6 satellites are generated for the terminal. If SBAS is to be tested one additional satellite shall be 
generated. AWGN channel model is used. The number of simulated satellites for each constellation is as defined in 
Table 6.8. 
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Table 6.7: Test parameters 



System 


Parameters 


Unit 


Value 




Number of generated satellites per system 


- 


See Table 6.8 


Total number of generated satellites 


- 


6 or 7'^' 


HDOP Range 


- 


1.4 to 2.1 


Propagation conditions 


- 


AWGN 


GNSS coarse time assistance error range 


seconds 


±2 


GPS*" 


Reference signal power level for all satellites 


dBm 


-128.5 


Galileo 


Reference signal power level for all satellites 


dBm 


-127 


GLONASS 


Reference signal power level for all satellites 


dBm 


-131 


QZSS 


Reference signal power level for all satellites 


dBm 


-128.5 


SBAS 


Reference signal power level for all satellites 


dBm 


-131 


NOTE 1 : "GPS" here means GPS L1 G/A, Modernized GPS, or both, dependent on UE 

capabilities. 
NOTE 2: 7 satellites apply only for SBAS case. 



If QZSS is supported, one of the GPS satellites will be replaced by a QZSS satellite with respective signal support. If 
SBAS is supported, the SBAS satellite with the highest elevation will be added to the scenario. 

Table 6.8: Satellite allocation 





Satellite allocation for each constellation 


GNSS1^" 


GNSS 2^" 


GNSS 3^" 


SBAS 


Single constellation 


6 


— 


— 


1 


Dual constellation 


3 


3 


- 


1 


Triple constellation 


2 


2 


2 


1 


NOTE 1 : GNSS refers to global systems i.e., GPS, Galileo, GLONASS 



6.2.1 Minimum requirements (nominal accuracy) 

The position estimates shall meet the accuracy and response time requirements in Table 6.9. 

Table 6.9: Minimum requirements 



System 


Success rate 


2-D position error 


Max response time 


All 


95% 


15m 


20 s 



6.3 Dynamic Range 



The aim of a dynamic range requirement is to ensure that a GNSS receiver performs well when visible satellites have 
rather different signal levels. Strong satellites are likely to degrade the acquisition of weaker satellites due to their 
cross-correlation products. Hence, it is important in this test case to keep use AWGN in order to avoid loosening the 
requirements due to additional margin because of fading channels. This test case verifies the performance of the first 
position estimate. 

In this requirement 6 satellites are generated for the terminal. Two different reference power levels, denoted as "high" 
and "low" are used for each GNSS. The allocation of "high" and "low" power level satellites depends on the number of 
supported GNSSs and it is defined in Table 6. 11. AWGN channel model is used. 
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Table 6.10: Test parameters 



System 


Parameters 


Unit 


Value 




Number of generated satellites per system 


- 


See Table 6.11 


Total number of generated satellites 


- 


6 


HDOP Range 


- 


1.4 to 2.1 


Propagation conditions 


- 


AWGN 


GNSS coarse time assistance error range 


seconds 


+2 


Galileo 


Reference tiigti signal power level 


dBm 


TBD 


Reference low signal power level 


dBm 


TBD 


GPS'^' 


Reference tiigh signal power level 


dBm 


-129 


Reference low signal power level 


dBm 


-147 


GLONASS 


Reference higli signal power level 


dBm 


-131.5 


Reference low signal power level 


dBm 


-147 


NOTE 1 : "GPS" liere means GPS L1 G/A, Modernized GPS, or botli, dependent on UE 
capabilities. 



Table 6.11 : Power level and satellite allocation 







Satellite allocation for each constellation 




GNSS1*" 


GNSS 2^" 


GNSS 3*" 


Single constellation 


High signal level 


2 


- 


- 


Low signal level 


4 


- 


- 


Dual constellation 


High signal level 


1 


1 


- 


Low signal level 


2 


2 


- 


Triple constellation 


High signal level 


1 


1 


1 


Low signal level 


1 


1 


1 


NOTE 1 : GNSS refers to global systems i.e., GPS, Galileo, GLONASS 



6.3.1 Minimum requirements (dynamic range) 

The position estimates shall meet the accuracy and response time requirements in Table 6.12. 

Table 6.12: Minimum requirements 



System 


Success rate 


2-D position error 


Max response time 


All 


95% 


100 m 


20 s 



6.4 



Multi-Path scenario 



The purpose of the test case is to verify the receiver's tolerance to multipath while keeping the test setup simple. This 
test case verifies the performance of the first position estimate. 

In this requirement 6 satellites are generated for the terminal. Some of the satellites have a one tap channel representing 
the Line-Of-Sight (LOS) signal. The other satellites have a two-tap channel, where the first tap represents the LOS 
signal and the second represents a reflected and attenuated signal as specified in Annex C.2. The number of satellites 
generated for each GNSS as well as the channel model used depends on the number of systems supported by the UE 
and is defined in Table 6.14. The channel model as specified in Annex C.2 further depends on the generated signal. 
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Table 6.13: Test parameter 



System 


Parameters 


Unit 


Value 




Number of generated satellites per system 


- 


See Table 6.14 


Total number of generated satellites 


- 


6 


HDOP range 




1.4 to 2.1 


Propagation conditions 


- 


AWGN 


GNSS coarse time assistance error range 


seconds 


+2 


Galileo 


Reference signal power level 


dBm 


-127 


GPS*" 


Reference signal power level 


dBm 


-128.5 


GLONASS 


Reference signal power level 


dBm 


-131 


NOTE 1 : "GPS" here means GPS L1 G/A, Modernized GPS, or both, dependent on UE 
capabilities. 



Table 6.14: Channel model allocation 







Channel model allocation for each 
constellation 




GNSS-1 


GNSS-2 


GNSS-3 


Single constellation 


One-tap channel 


2 


— 


— 


Two-tap channel 


4 


- 


- 


Dual constellation 


One-tap channel 


1 


1 


- 


Two-tap channel 


2 


2 


- 


Triple constellation 


One-tap channel 


1 


1 


1 


Two-tap channel 


1 


1 


1 



6.4.1 Minimum Requirements (multi-patin scenario) 

The position estimates shall meet the accuracy and response time requirements in Table 6.15. 

Table 6.15: Minimum requirements 



System 


Success rate 


2-D position error 


Max response time 


All 


95% 


100 m 


20 s 



6.5 Moving scenario and periodic update 

The purpose of the test case is to verify the receiver's capability to produce GNSS measurements or location fixes on a 
regular basis, and to follow when it is located in a vehicle that slows down, turns or accelerates. A good tracking 
performance is essential for a certain location services. A moving scenario with periodic update is well suited for 
verifying the tracking capabilities of an A-GNSS receiver in changing UE speed and direction. In the requirement the 
UE moves on a rectangular trajectory, which imitates urban streets. AWGN channel model is used. This test is not 
performed as a Time to First Fix (TTFF) test. 

In this requirement 6 satellites are generated for the terminal. The UE is requested to use periodical reporting with a 
reporting interval of 2 seconds. 

The UE moves on a rectangular trajectory of 940 m by 1 440 m with rounded corner defined in Figure 6.1. The initial 
reference is first defined followed by acceleration to final speed of 100 km/h in 250 m. The UE then maintains the 
speed for 400 m. This is followed by deceleration to final speed of 25 km/h in 250 m. The UE then turn 90 degrees with 
turning radius of 20 m at 25 km/h. This is followed by acceleration to final speed of 100 km/h in 250 m. The sequence 
is repeated to complete the rectangle. 
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Table 6.16: Trajectory Parameters 



Parameter 


Distance (m) 


Speed (km/h) 


'l1' 'l5' '2I' '25 


20 


25 


'l2' 'l4' '22' '24 


250 


25 to 100 and 100 to 25 


Il3 


400 


100 


'23 


900 


100 



*14 



lli± 



1440 m 


940 m 

r = 20m 
1/ 



H h 

'21 '22 



'23 



24 25 



Figure 6.1 : Rectangular trajectory of the moving scenario and periodic update test case 

Table 6.17: Test Parameters 



System 


Parameters 


Unit 


Value 




Number of generated satellites per system 


- 


See Table 6.18 


Total number of generated satellites 


- 


6 


HDOP Range per system 


- 


1.4 to 2.1 


Propagation conditions 


- 


AWGN 


GNSS coarse time assistance error range 


seconds 


±2 


Galileo 


Reference signal power level for all satellites 


dBm 


-127 


GPS*" 


Reference signal power level for all satellites 


dBm 


-128.5 


GLONASS 


Reference signal power level for all satellites 


dBm 


-131 


NOTE 1 : "GPS" here means GPS LI G/A, Modernized GPS, or botli, dependent on UE 
capabilities. 



Table 6.18: Satellite allocation 





Satellite allocation for each constellation 


GNSS1*" 


GNSS 2*'' 


GNSS 3*" 


Single constellation 


6 


- 


- 


Dual constellation 


3 


3 


- 


Triple constellation 


2 


2 


2 


N0TE1 : GNSS refers to global systems i.e., GPS, Galileo, GLONASS 



6.5.1 Minimum Requirements (moving scenario and periodic update) 

The position estimates shall meet the accuracy requirement of Table 6.19 with the periodical reporting interval defined 
in Table 6.19 after the first reported position estimates. 

NOTE: In the actual testing the UE may report error messages until it has been able to acquire GNSS measured 
results or a position estimate. The test equipment shall only consider the first measurement report 
different from an error message as the first position estimate in the requirement in Table 6.19. 
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Table 6.19: Minimum requirements 



System 


Success rate 


2-D position error 


Periodical reporting interval 


All 


95% 


50 m 


2s 
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Annex A (normative): 
Test cases 

A.1 Conformance tests 

The conformance tests are specified in 3GPP TS 36.xxx [3]. Statistical interpretation of the requirements is described in 

clause A.2. 



A.2 Requirement classification for statistical testing 

Requirements in the present document are either expressed as absolute requirements with a single value stating the 
requirement, or expressed as a success rate. There are no provisions for the statistical variations that will occur when the 
parameter is tested. 

Annex B lists the test parameters needed for the tests. The test will result in an outcome of a test variable value for the 
DUT inside or outside the test limit. Overall, the probability of a "good" DUT being inside the test limit(s) and the 
probability of a "bad" DUT being outside the test limit(s) should be as high as possible. For this reason, when selecting 
the test variable and the test limit(s), the statistical nature of the test is accounted for. 

When testing a parameter with a statistical nature, a confidence level has to be set. The confidence level establishes the 
probability that a DUT passing the test actually meets the requirement and determines how many times a test has to be 
repeated. The confidence levels are defined for the final tests in 3GPP TS 36.xxx [3]. 
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Annex B (normative): 
Test conditions 

B.1 General 

This annex specifies the additional parameters that are needed for the test cases specified in clauses 5 and 6 and applies 
to all tests unless otherwise stated. 

B.1.1 Parameter values 

Additionally, amongst all the listed parameters (see annex E), the following values for some important parameters are to 
be used in the LPP Request Location Information message. 

Table B.1 : Parameter values 



Information element 


Value - TTFF tests 

(except nominal 

accuracy test) 


Value - TTFF tests 

(nominal accuracy 

test) 


Value - Periodic tests 


periodicalReporting 


Not present 


Not present 


Present 


reportingAmount 


N/A 


N/A 


Infinite (see note) 


reportinglnterval 


N/A 


N/A 


2 (seconds) 


horizontalAccuracy 


51 .2 (m) 


16 (m) 


51.2 (m) 


responselime 


20 (seconds) 


20 (seconds) 


Not present 


NOTE: Infinite means during the complete test time. 



In the Sensitivity test case with Fine Time Assistance, the following parameter values are used. 

Table B.2: Parameters for Fine Time Assistance test 



Information element 


Value 


Networklime frameDrift 





GNSS-ReferencelimeForOneCell 
referenceTimeUnc 


11.11 (lis) 



B.1. 2 Time assistance 

For every Test Instance in each TTFF test case, the IE gnss-TimeOfDay shall have a random offset, relative to GNSS 
system time, within the error range of Coarse Time Assistance defined in the test case. This offset value shall have a 
uniform random distribution. 

In addition, for every Fine Time Assistance Test Instance the IE networkTime shall have a random offset, relative to the 
true value of the relationship between the two time references, within the error range of Fine Time Assistance defined in 
the test case. This offset value shall have a uniform random distribution. 

For the Moving Scenario and Periodic Update Test Case the IE gnss-TimeOfDay shall be set to the nominal value. 

B.1 .3 GNSS Reference Time 

For every Test Instance in each TTFF test case, the GNSS reference time shall be advanced so that, at the time the fix is 
made, it is at least 2 minutes later than the previous fix. 
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B.1 .4 Reference and UE locations 

There is no limitation on the selection of the reference location, consistent with achieving the required HDOP for the 
Test Case. For each test instance the reference location shall change sufficiently such that the UE shall have to use the 
new assistance data. The uncertainty of the semi-major axis is 3 km. The uncertainty of the semi-minor axis is 3 km. 
The orientation of major axis is degrees. The uncertainty of the altitude information is 500 m. The confidence factor is 

68%. 

For every Test Instance in each TTFF test case, the UE location shall be randomly selected to be within 3 km of the 
Reference Location. The Altitude of the UE shall be randomly selected between m to 500 m above WGS-84 reference 
ellipsoid. These values shall have uniform random distributions. 

For test cases which include satellites from regional systems, such as QZSS and SBAS, the reference location shall be 
selected within the defined coverage area of the systems. 

B.1 .5 Satellite constellation and assistance data 
B.1 .5.1 UE supports A-GPS LI C/A only 

In the case of test cases in clause 5 (UE supports A-GPS LI C/A only), the GPS satellite constellation shall consist of 
24 satellites. Almanac assistance data shall be available for all these 24 satellites. At least 9 of the satellites shall be 
visible to the UE (that is above 5 degrees elevation with respect to the UE). Other assistance data shall be available for 9 
of these visible satellites. In each test, signals are generated for only a sub-set of these satellites for which other 
assistance data is available. The number of satellites in this sub-set is specified in the test. The satellites in this sub-set 
shall all be above 15 degrees elevation with respect to the UE. The HDOP for the test shall be calculated using this sub- 
set of satellites. The selection of satellites for this sub-set shall be random and consistent with achieving the required 
HDOP for the test. 

B.1 .5.2 UE supports other A-GNSSs 

In the case of test cases in clause 6 (UE supports other GNSSs), the satellite constellation shall consist of 24 satellites 
for GLONASS; 27 satellites for GPS, Modernized GPS and GaUleo; 3 satellites for QZSS; and 2 satellites for SBAS. 
Almanac assistance data shall be available for all these satellites. At least 7 of the satellites per GPS, Modernized GPS, 
Galileo or GLONASS constellation shall be visible to the MS (that is, above 15 degrees elevation with respect to the 
MS). At least 1 of the satellites for QZSS shall be within 15 degrees of zenith; and at least 1 of the satellites for SBAS 
shall be visible to the MS. All other satellite specific assistance data shall be available for all visible satellites. In each 
test, signals are generated for only 6 satellites (or 7 if SBAS is included). The HDOP for the test shall be calculated 
using these satellites. The simulated satellites for GPS, Modernized GPS, Galileo and GLONASS shall be randomly 
selected from the visible satellites for each constellation. 

B.1. 6 Atmospheric delays 

Typical Ionospheric and Tropospheric delays shall be simulated and the corresponding values inserted into the GNSS- 
lonospheric Model IE. 

B.1 .7 E-UTRA Frequency and frequency error 

In all test cases the E-UTRA frequency used shall be the mid range for the E-UTRA operating band. The E-UTRA 
frequency with respect to the GNSS carrier frequency shall be offset by H-0.025 PPM. 

B.1. 8 Information elements 

The information elements that are available to the UE in all the test cases are listed in annex E. 
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B.1.9 GNSS signals 



The GNSS signal is defined at the A-GNSS antenna connector of the UE. For UE with integral antenna only, a 
reference antenna with a gain of dBi is assumed. 

B.1.10 RESET UE POSITIONING STORED INFORMATION 
Message 

In order to ensure each Test Instance in each TTFF test is performed under Time to First Fix (TTFF) conditions, a 
dedicated test signal (RESET UE POSITIONING STORED INFORMATION) defined in TS 36.509 [11] clause 6.9 shall 
be used. 

When the UE receives the 'RESET UE POSITIONING STORED INFORMATION signal, with the IE UE 
POSITIONING TECHNOLOGY set to AGNSS it shall: 

discard any internally stored GNSS reference time, reference location, and any other aiding data obtained or 
derived during the previous test instance (e.g. expected ranges and Doppler); 

accept or request a new set of reference time or reference location or other required information, as in a TTFF 
condition; 

calculate the position or perform GNSS measurements using the 'new' reference time or reference location or 
other information. 



B.1 .1 1 GNSS System Time Offsets 



If more than one GNSS is used in a test, the accuracy of the GNSS-GNSS Time Offsets used at the system simulator 
shall be better than 3 ns. 

B.1.12 Sensors 

The minimum performances shall be met without the use of any data coming from sensors that can aid the positioning. 
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Annex C (normative): 
Propagation conditions 

C.1 Static propagation conditions 

The propagation for the static performance measurement is an Additive White Gaussian Noise (AWGN) environment. 
No fading and multi-paths exist for this propagation model. 



C.2 IVIulti-path Case 



Doppler frequency difference between direct and reflected signal paths is applied to the carrier and code frequencies. 
The Carrier and Code Doppler frequencies of LOS and multi-path for GNSS signal are defined in table C.l. 

Table C.1 : Multipath Case 



Initial relative Delay 
[m] 







X 



Carrier Doppler 
frequency of tap [Hz] 



Fd 



Fd-0.1 



Code Doppler 
frequency of tap [Hz] 



Fd/N 



NOTE: Discrete Doppler frequency is used for each tap 



(Fd-0.1 )/N 



Relative mean Power 
[dB] 







Y 



Where the X and Y depends on the GNSS signal type and is shown in Table C.2, and N is the ratio between the 
transmitted carrier frequency of the signals and the transmitted chip rate as shown in Table C.3 (where k in Table C.3 is 
the GLONASS frequency channel number). 

Table C.2: Parameter values 



System 


Signals 


X[m] 


Y[dB] 


Galileo 


E1 


125 


[-4.5] 


E5a 


15 


-6 


E5b 


15 


-6 


GPS/Modernized 
GPS 


L1 G/A 


150 


-6 


L1G 


125 


[-4.5] 


L2G 


150 


-6 


L5 


15 


-6 


GLONASS 


G1 


275 


-12.5 


G2 


275 


-12.5 



Table C.3: Ratio between Carrier Frequency and Chip Rate 



System 


Signals 


N 


Galileo 


El 


1540 


E5a 


115 


E5b 


118 


GPS/Modernized 
GPS 


LI C/A 


1540 


Lie 


1540 


L2G 


1200 


L5 


115 


GLONASS 


G1 


3135.03 + k- 1.10 


G2 


2438.36 + k ■ 0.86 



The initial carrier phase difference between taps shall be randomly selected between and 2n. The initial value shall 
have uniform random distribution. 
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Annex D (normative): 
Measurement sequence chart 

D.1 General 

The measurement Sequence Charts that are required in all the test cases, are defined in this clause. 

D.2 TTFF Measurement Sequence Chart 

The measurement sequence chart for the TTFF test cases, for both UE-assisted and UE-based GNSS, is defined in this 
subclause. 



ss 



(a) 
(b) 

(c) 
(d) 
(e) 
(f) 

(g) 



UE 



Reset UE Positioning Stored Information 



LPP Request Capabilities 



LPP Provide Capabilities 



LPP Provide Assistance Data 



LPP Provide Assistance Data 



LPP Request Location Information 



LPP Provide Location Information 



Response Time 



(a) 
(b) 
(c) 



The system simulator sends a RESET UE POSITIONING STORED INFORMATION message with the 
IE UE POSITIONING TECHNOLOGY set to AGNSS. 

The system simulator sends a LPP message of type REQUEST CAPABILITIES including the 
a-gnss-RequestCapabilities IE set to TRUE. 

The UE sends a LPP message of type PROVIDE CAPABILITIES including the 

A-GNSS-ProvideCapabilities IE with the AssistanceDataSupportList included, indicating the assistance 
data supported by the UE. 



(d) - (e) The system simulator provides the assistance data that are supported by the UE and available as defined 
in Annex E and Table E.l in one or more LPP messages of type PROVIDE ASSISTANCE DATA. 

(f) The system simulator sends a LPP message of type REQUEST LOCATION INFORMATION including 
the information elements defined in Table D.L 

(g) The UE sends a LPP message of type PROVIDE LOCATION INFORMATION including either the 
GNSS-SignalMeasurementlnformation or GNSS-Locationlnformation IE, dependent on the test case (UE- 
assisted or UE-based, respectively). 
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Steps (a) to (g) are repeated for each test instance. 



Table D.I : LPP Request Location Information Content for TTFF Test Cases. 



Information Element 


Value/remark 


Comment 


RequestLocationlnformation 






>commonlEsRequestLocationlnformation 






» locationlnformationType 


"locationEstimateRequired" or 
"locationMeasurementsRequired" 


Depending on test 
case and UE 
capabilities, i.e., UE- 
based or UE-assisted 


» assistanceAvailability 


"serverAssistanceAvailable" 


The UE may send a 
LPP message of type 
REQUEST 
ASSISTANCE DATA 
between step (f) and 
(g), and the SS shall 
fulfill any such 
request. 


» additionallnformation 


"onlyReturnlnformationRequested" 




»qos 






>» horizontalAccuracy 


As defined in Annex B.1 .1 




>» verticalCoordinateRequest 


FALSE 




>» responseTime 


"20" 




> a-gnss-RequestLocationlnformation 






» gnss-Positioninglnstructions 






>» gnssMethods 






»» preferredMode 


"ue-based" or "ue-assisted" 


Depending on test 
case and UE 
capabilities, i.e., UE- 
based or UE-assisted 


»» gnss 


According to UE capabilities 




>» fineTimeAssistanceMeasReq 


FALSE 




>» adrMeasReq 


FALSE 




>» multlFreqMeasReq 


TRUE or FALSE 


Depending on UE 
capabilities 



D.3 Moving Scenario And Periodic Update IVIeasurement 
Sequence Chart 

The measurement sequence chart for the moving scenario and periodic update test case, for both UE-assisted and UE- 
based GNSS, is defined in this subclause. 
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ss 


Reset UE Positioning Stored Information 


UE 


(a) 
(b) 
(c) 
(d) 
(e) 
(f) 

(g) 

(h) 
(i) 










LPP Request Capabilities 






^ 


LPP Provide Capabilities 








LPP Provide Assistance Data 


^ 






LPP Provide Assistance Data 


^ 






LPP Request Location Information 






^ 


LPP Provide Location Information 








LPP Provide Location Information 






^ 


• 
• 

LPP Provide Location Information 















(a) The system simulator sends a RESET UE POSITIONING STORED INFORMATION message with the 
IE UE POSITIONING TECHNOLOGY set to AGNSS. 

(b) The system simulator sends a LPP message of type REQUEST CAPABILITIES including the 
a-gnss-RequestCapabilities IE set to TRUE. 

(c) The UE sends a LPP message of type PROVIDE CAPABILITIES including the 
A-GNSS-ProvideCapabilities IE with the AssistanceDataSupportList included, indicating the assistance 
data supported by the UE. 

(d) - (e) The system simulator provides the assistance data that are supported by the UE and available as defined 

in Annex E and table E.l in one or more LPP messages of type PROVIDE ASSISTANCE DATA. 

(f) The system simulator sends a LPP message of type REQUEST LOCATION INFORMATION including 
the information elements defined in Table D.2. 

(g) - (i) The UE provides LPP messages of type PROVIDE LOCATION INFORMATION including either the 

GNSS-SignalMeasurementlnformation or GNSS-Locationlnfomiation IE, dependent on the test case (UE- 
assisted or UE-based, respectively) until the moving trajectory has been completed. 

NOTE: The UE may report error messages at step (g) until it has been able to acquire GNSS signals. 
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Table D.2: LPP Request Location Information Content for Moving Scenario And Periodic Update Test 

Case. 



Information Element 


Value/remark 


Comment 


RequestLocationlnformation 






> common lEsRequestLocationlnformation 






» locationlnformationType 


"locationEstimateRequired" or 
"locationMeasurementsRequired" 


Depending on test 
case and UE 
capabilities, i.e., UE- 
based or UE-assisted 


» periodicalReporting 






>» reportingAmount 


"ra-lnfinity" 


As defined in Annex 
B.1.1 


>» reportinglnterval 


ri2 


As defined in Annex 
B.1.1 


» assistanceAvailability 


"serverAssistanceAvailable" 


The UE may send a 
LPP message of type 
REQUEST 
ASSISTANCE DATA 
at any time after step 
(f), and the SS shall 
fulfill any such 
request. 


» additionallnformation 


"onlyReturnlnformatlonRequested" 




»qos 






>» horizontalAccuracy 


As defined in Annex B.1 .1 




>» verticalCoordinateRequest 


FALSE 




> a-gnss-RequestLocationlnformation 






» gnss-Positioninglnstructions 






>» gnsslVlethods 






»» preferredMode 


"ue-based" or "ue-assisted" 


Depending on test 
case and UE 
capabilities, i.e., UE- 
based or UE-assisted 


»» gnss 


According to UE capabilities 




>» fineTimeAssistancelVleasReq 


FALSE 




>» adrMeasReq 


FALSE 




>» multlFreqMeasReq 


FALSE 
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Annex E (normative): 

Assistance data required for testing 

E.1 Introduction 

This annex defines the assistance data lEs available at the SS in all test cases. The assistance data shall be given for 
satellites as defined in B. 1.5. 

The information elements are given with reference to 3GPP TS 36.355 [4], where the details are defined. 

Table E. 1 defines the assistance data elements which shall be provided to the UE in the tests (steps (d) and (e) in the 
message sequence according to annexes D.2 and D.3). The assistance data provided depends on the mode being used in 
the test case, the assistance data supported by the UE (indicated in step (c) in the message sequence according to 
annexes D.2 and D.3) and the GNSSs supported by the UE. Assistance data lEs not supported by the UE shall not be 
sent. Assistance data lEs supported by the UE but not listed in Table E.l shall not be sent. 

Table E.1 : Assistance Data to be provided to the UE 



Assistance Data IE supported 
byUE 


Mode used in test case 


UE-based 


UE-assisted, 
GNSS- 
AcquisitionAssistance 
supported by UE 


UE-assisted, 
GNSS- 
AcquisitionAssistance 
not supported by UE 


GNSS-Reference Time 


Yes 


Yes 


Yes 


GNSS-ReferenceLocation 


Yes 


No 


Yes 


GNSS-lonosphericModel 


Yes 


No 


No 


GNSS-TimeModelList 


Yes*" 


No 


Yes*" 


GNSS-NavigationModel 


Yes 


No 


Yes 


GNSS-AcquisitionAssistance 


No 


Yes 


No 


GNSS-Almanac 


No 


No 


Yes 


GNSS-UTC-Model 


Yes 


No 


No 


GNSS-Auxiliary Information 


Yes*^' 


Yes*^' 


Yes*^' 


NOTE 1 : In case more than a single GNSS is supported by the UE. 

NOTE 2: In case the UE supports GLONASS, or more than one GNSS signal. 



E.2 GNSS Assistance Data 



a) GNSS- Reference Time IE. This information element is defined in subclause 6.5.2.2 of 3GPP TS 36.355 [4]. 
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Table E.2: GNSS- Reference Time IE 



Information Element 


All tests except 
Sensitivity Fine 
Time Assistance 


Sensitivity Fine 

Time Assistance 

test 


GNSS-ReferenceTime 






> gnss-Systemlime 






» gnss-TimelD 


Yes 


Yes 


» gnss-DayNumber 


Yes 


Yes 


» gnss-TimeOfDay 


Yes 


Yes 


» gnss-TimeOfDayFrac-msec 


Yes 


Yes 


» notificationOfLeapSecond 


Yes if 

gnss-TimelD = 
"glonass" 


Yes if 

gnss-TimelD = 
"glonass" 


» gps-TOW-Assist 


Yes if 
gnss-TimelD = "gps" 


Yes if 
gnss-TimelD = 

"gps" 


> referencelimeUnc 


Yes 


No 


> gnss-ReferenceTimeForOneCell 


No 


Yes 


» networl<Time 




Yes 


>» secondsFromFrameStructureStart 




Yes 


»>fractionalSecondsFromFrameStructu restart 




Yes 


>» frameDrift 




Yes 


»>celllD 




Yes 


»» pliysCellld 




Yes 


»» cellGloballdEUTRA 




Yes 


» referenceTimeUnc 




Yes 



b) GNSS-ReferenceLocation IE. This information element is defined in subclause 6.5.2.2 of 3GPP TS 36.355 [4]. 

Table E.3: GNSS-ReferenceLocation IE 



Name of the IE 


Fields of the IE 


GNSS-ReferenceLocation 


threeDlocation 



c) GNSS-IonosphericModel IE. This information element is defined in subclause 6.5.2.2 of 3GPP TS 36.355 [4]. 

Table E.4: GNSS-lonosphericlVlodel IE 



Name of the IE 


Fields of the IE 


GNSS-lonosphericModel 


KlobucharModelParameter 




NeOuickModelParameter'^' 


NOTE 1 : Only required if GNSSs supported include Galileo. 



d) GNSS-TimeModelList IE. This information element is only required for multi system tests, and is defined in 
subclause 6.5.2.2 of 3GPP TS 36.355 [4]. 

Table E.5: GNSS-TimelUlodelList IE 



Name of the IE 


Fields of the IE 


GNSS-TimelVlodelList 






gnssTOID 

For each GNSS included in the 

test. 




deltaT 



e) GNSS-NavigationModel IE. This information element is defined in subclause 6.5.2.2 of 3GPP TS 36.355 [4]. 
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Table E.6: GNSS-NavlgationModel IE 



Name of the IE 


Fields of the IE 


GNSS-NavigationModel 





Table E.7: GNSS Clock and Orbit Model Choices 



GNSS 


Clock and 

Orbit Model 

Choice 


GPS 


Model-2 


Modernized GPS 


Model-3 


GLONASS 


Model-4 


QZSS QZS-L1 


Model-2 


QZSSQZS-L1C/L2G/L5 


Model-3 


SBAS 


Model-5 


Galileo 


Model-1 



f) GNSS-AcquisitionAssistance IE. This information element is defined in subclause 6.5.2.2 of 3GPP TS 36.355 
[4]. 

Table E.8: GNSS-AcquisitionAssistance IE 



Name of the IE 


Fields of the IE 


GNSS-AcquisitionAssistance 





g) GNSS-Almanac IE. This information element is defined in subclause 6.5.2.2 of 3GPP TS 36.355 [4]. 

Table E.9: GNSS-Almanac IE 



Name of the IE 


Fields of the IE 


GNSS-Almanac 





Table E.10: GNSS Almanac Choices 



GNSS 


Almanac 
Model Choice 


GPS 


Model-2 


Modernized GPS 


Model-3,4 


GLONASS 


Model-5 


QZSS QZS-L1 


Model-2 


QZSS QZS-L1 C/L2G/L5 


Model-3,4 


SBAS 


Model-6 


Galileo 


Model-1 



h) GNSS-UTC-Model IE. This information element is defined in subclause 6.5.2.2 of 3GPP TS 36.355 [4]. 

Table E.11: GNSS-UTC-Model IE 



Name of the IE 


Fields of the IE 


GNSS-UTC-Model 
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Table E.12: GNSS UTC Model Choices 



GNSS 


UTC Model Choice 


GPS 


Model-1 


Modernized GPS 


Model-2 


GLONASS 


Model-3 


QZSS QZS-L1 


IVIodel-1 


QZSSQZS-L1G/L2C/L5 


Model-2 


SBAS 


Model-4 


Galileo 


Model-1 



i) GNSS-Auxiliarylnformation IE. This information element is defined in subclause 6.5.2.2 of 3GPP TS 36.355 
[4]. 

Table E.13: GNSS-Auxiliarylnformation IE 



Name of the IE 


Fields of the IE 


GNSS-Auxiliarylnformation 
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Annex F (normative): 

Converting UE-assisted measurement reports into position 

estimates 

F.1 Introduction 

To convert the UE measurement reports in case of UE-assisted mode of A-GNSS into position errors, a transformation 
between the "measurement domain" (code-phases, etc.) into the "state" domain (position estimate) is necessary. Such a 
transformation procedure is outlined in the following clauses. The details can be found in [8-10] and [12-17]. 

F.2 UE measurement reports 

In case of UE-assisted A-GNSS, the measurement parameters are contained in the LPP GNSS- 
SignalMeasurementlnformation IE (subclause 6.5.2.6 in 3GPP TS 36.355 [4]). The measurement parameters required 
for calculating the UE position are: 

1) Reference Time: The UE has two choices for the Reference Time: 

a) "networkTime"; 

b) "gnss-TOD-msec". 

2) Measurement Parameters for each GNSS and GNSS signal: 1 to 64: 

a) " svID "; 

b) "codePhase"; 

c) "integerCodePhase"; 

d) "codePhaseRMSError". 

Additional information required at the system simulator: 

1) "GNSS-ReferenceLocation" (subclause 6.5.2.2 in 3GPP TS 36.355 [4]): 
Used for initial approximate receiver coordinates. 

2) "GNSS-NavigationModel" (subclause 6.5.2.2 in 3GPP TS 36.355 [4]): 

Contains the GNSS ephemeris and clock correction parameters as specified in the relevant ICD of each 
supported GNSS; used for calculating the satellite positions and clock corrections. 

3) "GNSS-IonosphericModel" (subclause 6.5.2.2 in 3GPP TS 36.355 [4]): 

Contains the ionospheric parameters which allow the single frequency user to utilize the ionospheric model as 
specified in the relevant ICD of each supported GNSS for computation of the ionospheric delay. 
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F.3 WLS position solution 



The WLS position solution problem is concerned with the task of solving for four unknowns; x^, y^^, z^ the receiver 
coordinates in a suitable frame of reference (usually ECEF) and b^^ the receiver clock bias. It typically requires the 
following steps: 

Step 1: Formation of pseudo-ranges 

The observation of code phase reported by the UE for each satellite S Vj is related to the pseudo-range/c modulo the 
"gnss-CodePhaseAmbiguity". For the formation of pseudo-ranges, the integer number of milliseconds to be added to 
each code-phase measurement has to be determined first. Since 1 ms corresponds to a travelled distance of 300 km, the 
number of integer ms can be found with the help of reference location and satellite ephemeris. The distance between the 
reference location and each satellite SVj is calculated and the integer number of milli-seconds to be added to the UE 
code phase measurements is obtained. 

Step 2: Correction of pseudo-ranges for the GNSS-GNSS time offsets 

In the case that the UE reports measurements for more than a single GNSS, the pseudo-ranges are corrected for the time 
offsets between the GNSSs relative to the selected reference time using the GNSS-GNSS time offsets available at the 
system simulator: 

PcNSS„,,i ~ PcNSS„J ~ ^ ' ^''CNSSt ~ ''CNSS„, > ' 

where Pqj^ss ; ^^ '■^^ measured pseudo-range of satellite / of GNSSm. The system time t^j^^^ of GNSSk is the reference 
time frame, and (^c^^^ — ^cnss ) ^^ '■^^ available GNSS-GNSS time offset, and c is the speed of light. 

Step 3: Formation of weighting matrix 

The UE reported "codePhaseRMSError" values are used to calculate the weighting matrix for the WLS algorithm [9]. 
According to 3GPP TS 36.355 [4], the encoding for this field is a 6 bit value that consists of a 3 bit mantissa, Xj and a 3 
bit exponent, Yj for each SVj: 

Wi = RMSError = 0.5x1 + ^x2^' 



The weighting Matrix W is defined as a diagonal matrix containing the estimated variances calculated from the 
"codePhaseRMSError" values: 

W = diag{l / wl^ss, ,1 '1 / ^Inss,,! ' • • • '1 / ^Inss, ^n^'-'M ^Inss^,x ^ ' ^Inss^,i '•••'!/ ^Inss^ ,1 } 
Step 4: WLS position solution 
The WLS position solution is described in reference [9] and usually requires the following steps: 

1) Computation of satellite locations at time of transmission using the ephemeris parameters and user algorithms 
defined in the relevant ICD of the particular GNSS. The satellite locations are transformed into WGS-84 
reference frame, if needed. 

2) Computation of clock correction parameters using the parameters and algorithms as defined in the relevant ICD 
of the particular GNSS. 

3) Computation of atmospheric delay corrections using the parameters and algorithms defined in the relevant ICD 
of the particular GNSS for the ionospheric delay, and using the Gupta model in reference [10] p. 121 equation 
(2) for the tropospheric delay. For GNSSs which do not natively provide ionospheric correction models (e.g., 
GLONASS), the ionospheric delay is determined using the available ionospheric model adapted to the particular 
GNSS frequency. 

4) The WLS position solution starts with an initial estimate of the user state (position and clock offset). The 
Reference Location is used as initial position estimate. The following steps are required: 
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a) Calculate geometric range (corrected for Earth rotation) between initial location estimate and each satellite 
included in the UE measurement report. 

b) Predict pseudo-ranges for each measurement including clock and atmospheric biases as calculated in 1) to 3) 
above and defined in the relevant ICD of the particular GNSS and [9]. 

c) Calculate difference between predicted and measured pseudo-ranges Ap 

d) Calculate the "Geometry Matrix" G as defined in [9]: 



G = 



^GNSS^,\ 




^GNSSi,2 




^GNSS, ,n 




^GNSS„, ,1 




^-GNSS^,! 




^GNSS„,l 


1 



with 1 



-r„ 



GNSS,,, J 



where r„ is the satellite position vector for SV; 



of GNSS„ (calculated in 1) above), and r^ is the estimate of the user location. 

e) Calculate the WLS solution according to [9]: 

Ax = (g^WgJT^G^WAp 

f) Adding the Ax to the initial state estimate gives an improved estimate of the state vector: 

X — > X + Ax . 

5) This new state vector x can be used as new initial estimate and the procedure is repeated until the change in x is 
sufficiently small. 

Step 5: Transformation from Cartesian coordinate system to Geodetic coordinate system 

The state vector x calculated in Step 4 contains the UE position in ECEF Cartesian coordinates together with the UE 
receiver clock bias relative to the selected GNSS system time. Only the user position is of further interest. It is usually 
desirable to convert from ECEF coordinates x^^, y^, z^ to geodetic latitude (() , longitude X and altitude h on the WGS84 
reference ellipsoid. 

Step 6: Calculation of "2-D Position Errors" 

The latitude cp / longitude X obtained after Step 5 is used to calculate the 2-D position error. 
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